Electronic commerce (“e-commerce”) has been increasing in popularity as more people are becoming accustomed to purchasing products online via the Internet. However, online transactions can raise security issues for merchants.
In a typical e-commerce transaction, a customer uses a web client (e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Wash. State) to access a merchant website hosted on a merchant server. The customer browses the merchant website selecting items to purchase. When the customer is ready to pay for the selected items, a checkout web page including a list of the items selected for purchase is displayed. To confirm the selection of items, the user selects a “checkout” button on the checkout web page.
Next, a payment web page is displayed to the customer. At the payment web page, the customer enters payment information for the e-commerce transaction. For example, the customer may be prompted to enter a credit card number, a billing address for the credit card number, and a shipping address for the items selected for purchase. Once the information is entered, the customer selects a “submit payment” button and the payment information is posted to the merchant server. The merchant server will then communicate the payment information to a server administered by a third party payment processor. The payment processor server will verify the information entered by the customer, process the payment, and communicate to the merchant server whether the payment was successful. Upon a successful payment, the merchant server will display a payment verification web page to the user.
An alternative method is commonly referred to as a “buyer push” payment method, in which the seller “pushes” funds to the merchant. A “buyer push” transaction may proceed as follows.
At a checkout web page downloaded to the customer's computer, the customer is presented with a virtual shopping cart listing all of the items the customer has selected to purchase. In addition, the checkout web page may list other transaction data, such as the price for each item, a sub-total for all items, any applicable tax, and a total cost of the transaction. When the customer selects the “checkout” button, the customer's computer communicates all of the transaction information to a third party server for payment processing via a Hypertext Transfer Protocol (HTTP) Post method.
The payment processor server receives the transaction information and then presents the user with a user credentials web page. The user credentials web page prompts the customer to enter a username and password for verification purposes. Once the customer enters a username and password, the customer selects the “OK” button to submit the user credentials to the payment processor server.
Upon successful verification, the customer is presented with a payment web page. At the payment web page, the customer selects a form of payment that is available to the customer based on the customer's user credentials and the customer's current account standings with the payment processor. For customers with existing accounts, a previously selected default shipping address is used. However, the customer might select an alternative shipping address at the payment web page. After entering the payment information, the customer selects the “submit payment” button to confirm the payment and to communicate the payment information to the third party payment processor server.
After receiving and validating the payment information, the payment processor server displays a payment confirmation web page and communicates the payment information to the merchant server with a payment status (e.g., whether the payment was successful). If the payment status indicates that the payment was successful, then the merchant server will display its own payment confirmation web page.
The “buyer push” method described has potential technical problems that can raise security concerns for merchants. In the traditional “buyer push” scheme described above, when the transaction information is communicated from the merchant checkout page to the third party payment processor, the transaction information is susceptible to being intercepted and/or modified. For example, the transaction information is simply embedded in a hypertext markup language (HTML) document and communicated to the third party payment processor server via the Hypertext Transfer Protocol (HTTP) Post method. Therefore, the transaction information can be viewed and edited by simply editing the source HTML document prior to submitting the data to the third party payment processor server. A customer might modify the payment price and pay less for a product than the merchant intended. Similarly, the status of the payment is communicated to the merchant server via the HTTP Post method and therefore subject to the same security issues. Consequently, security flaws exist in the traditional “buyer push” method.